為了抓跨 Session 濫用，我們準備留下多少資料？

[[我也希望安全第一]]｜第 21／30 天

從一筆不保存原文的風險訊號開始

若濫用者把一個惡意軟體任務拆成十次正常對話，單一 session 看起來都可能無害。OpenAI 的 Private Safety Processing 因此主打跨 conversation 分析，同時宣稱維持 Zero Data Retention：系統在私密處理環境中找出長期模式，只送出狹義風險訊號，不保留完整客戶內容。

這個方向很吸引人，公開資料卻還不足以讓外界驗證「完全不留資料」的具體實作、跨 session 準確率與誤判處理。先不替廠商補答案，假設我們自己要做，資料流至少長這樣：

prompt／tool event
      ↓ 私密處理環境
單次風險判斷 ──→ 原文依政策刪除
      ↓
最小風險事件 ──→ rolling account state
      ↓ 達門檻
人工覆核／能力降級／申訴
      ↓
到期、刪除及刪除證據

真正困難的是中間那筆「最小風險事件」。若只剩 high_risk=true，調查者不知道為什麼；若放進 prompt 摘要、embedding、帳號、IP、裝置和工具參數，它又逐漸長回一份可識別的行為檔案。ZDR 不能只回答原始 prompt 留不留，還要回答衍生狀態是什麼。

保留內容不是唯一選項

Anthropic 在 Fable／Mythos 5 推出時，曾要求部分高能力模型保留 30 天流量供濫用分析，即使企業原有零保留協議也受影響；5.1 又提供客戶自有環境與自管監控的折衷。兩種方案不是簡單的「安全」對「隱私」，而是把風險放在不同地方。

如果團隊說採 ZDR，應進一步交代：不保留原始 prompt，是否仍保存 account ID、token usage、tool event、風險 embedding、IP 或裝置資訊？這些欄位正是前面 rolling state 的材料。

誤判進入申訴後，資料反而變得更敏感

一筆跨 session 風險訊號若判錯，使用者可能從「沒有保存原文」走進另一條更敏感的流程。Anthropic 的政策允許在特定帳號申訴中要求政府證件、自拍或影片，並由 Persona 處理臉部幾何模板。這可能讓被誤判者證明自己，也建立了比原始對話更難更換的資料。

驗證流程至少要回答：

- 為什麼這次需要證件，而不是較低侵入性的驗證？
- 原圖、影片、臉部模板各由誰持有，多久刪除？
- 第三方 processor 能否另作他用，政府如何調取？
- 使用者拒絕生物辨識時是否有替代申訴方式？
- 刪除是否包含備份、衍生 template 與供應商副本？

「只適用少數人」不能代替 retention policy。監控、停權和申訴必須畫在同一張資料流上，否則前半段宣稱少收資料，後半段卻可能留下證件、副本和生物辨識 template。

沿著這條流程做資料治理矩陣

資料             目的           保留        存取者        刪除／撤銷
prompt 原文       個案調查       7 天例外     核准 IR 人員   case close + 7d
tool event        異常偵測       30 天        SOC           lifecycle rule
account risk flag 跨 session 關聯 30 天滾動    safety service  appeal／expiry
OAuth grant ID    憑證撤銷       grant+90 天  IAM／IR        grant deletion
證件原圖          身分申訴       驗證完成即刪 processor only deletion receipt
臉部 template     防重複詐欺     明定期限     隔離服務       user request／expiry

每一列都要有目的、期限、存取角色與可驗證刪除。若一份資料同時被拿去訓練、除錯、行銷分析和安全監控，purpose limitation 就只剩文件措辭。

Claude session token 遭竊的案例剛好可以測 OAuth grant 那一列。使用者若只看得到帳號總用量，很難判斷是哪個裝置或 grant 在消耗額度；活動紀錄太少，撤銷時找不到目標。反過來，若為方便調查而保存完整 token、prompt 和裝置細節，安全功能本身又變成新的資料庫。

比較合理的畫面是列出 grant ID、建立時間、最後使用時間、裝置標籤與大致活動，不顯示完整 secret；使用者可以撤銷單一 grant，IR 人員也能把撤銷動作連回事件。這不是額外的帳號功能，而是前面 rolling state 最後如何被使用者看見和控制。

安全監控也要有自己的停止條件

產品需求常寫「偵測跨 session 濫用」，很少寫什麼時候不再追蹤。最小規格應補上：風險狀態多久沒有新訊號便衰減、申訴成立後哪些衍生資料要清除、模型或規則改版後舊標籤是否重算，以及刪除工作失敗時由誰收到警示通知。

還要定期抽樣兩端：被攔下的人裡有多少是誤判；沒有被攔下的事故，又缺了哪一種訊號。只追成功阻擋數，資料自然只會愈收愈多。

下一篇要面對更難的情況：兒少、病患或心理危機中的使用者，可能沒有能力自行理解這些設定與風險。那時「讓使用者自己選」還夠不夠？

本篇的鎖

• 鎖是什麼：從單次判斷、rolling state、人工覆核到申訴的資料最小化、目的限制、保留期限、角色存取與可驗證刪除。
• 想攔什麼：為抓跨 session 濫用而無限保存內容，或為減少資料而完全失去調查、撤銷與申訴能力。
• 破口在哪：ZDR 可能只排除原文而保留衍生訊號；客戶自管可能關閉監控，申訴身分驗證又建立新的高敏感資料。
• 怎麼補：逐資料欄位寫出目的、期限、存取者與刪除證據；用最小事件訊號做關聯，把完整內容限制在有門檻、短期、可稽核的例外流程。

參考與來源

• 跨 session 監控：原始報導
• 身分驗證：原始報導
• 自管監控：原始報導
• 憑證可觀測性：原始報導